The present invention relates generally to computing systems and in particular to a method of determining whether a process has terminated in a environment in which a one operating system is being simulated and runs on top of a second operating system, and the possibly terminated process runs in conjunction principally with the simulated operating system.
Application programs or processes are normally written to run on specific systems, i.e., in conjunction with a specific operating system that performs supervisory control of system resource allocation (e.g., allocation and usage of such system resources as memory, processing time, disk space, peripheral devices, and the like). Use of these processes over time verifies their credibility and operability. The more useful processes become the objects of "porting," transference to other operating systems different from that for which they were originally designed. This will typically require that the process be rewritten for the new operating system, and if the new operating system is substantially different, or the program language in which the process was originally developed is particularly difficult for the new operating system, the porting process can become a tedious task. The porting procedure can, therefore, be time consuming and expensive, depending upon the process, the structure of the old and new operating systems, and other reasons not necessarily relevant here. For this reason, it may be desirable to simulate the old operating system in the new operating system environment so that the process being ported does not need to be substantially revised--if at all.
However, simulating an operating system in order to allow porting of a process or processors may carry with it additional problems. One such problem arises when the simulated operating system has not yet been informed that a ported process (i.e., one that thinks it is running under the simulated operating system) has terminated, and another ported process requests communication with the terminated ported process, and receives back an error. This problem arises, in part, from the fact that among the normal tasks of an operating system is the responsibility of keeping track of the current state of processes running under it, i.e., whether the process is running, is suspended, is stopped, or has terminated. Generally, when a process requests communication access to a terminated process and receives back an error, that the process relays to the operating system, the operating system can check to see if in fact the error resulted from termination of the target process or a fault. Conventional techniques for such monitoring involves keeping global data structures that contain information that reflect the current state of each process called into existence. The data structures can keep an identification (ID) of each ported process when the process is instantiated. However, this ID is often reused so that checking the data structure to determine if a process is terminated can provide misleading results. Simulating an operating system results in a delay between termination of a ported process and notification of that termination to the simulated operating system. It is during this delay that the problem referred to above arises.
Thus, it can be seen that there is needed a way to provide notification of termination of a ported process in an environment in which the ported process is running (or thinks it is running) under a simulated operating system that, in turn, is running under an actual or native operating system different from that simulated.